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Abstract 

*  One  of  the  major  obstacles  to  the  widespread  develops nt  and  utiliza¬ 
tion  of  distributed  data  base  management  systems  is  the  lack  of  an  efficient 
recovery  technique.  A  methodology  i‘s  present  here  for  recovery  of  distributed 
data  bases.  The  central  operation  of  the  recovery  technique  is  rollback  of 
a  data  base  application  task  on  the  processor  which  controls  access  to  the 
data.  The  rollback  procedure  restores  the  data  base  to  its  original  state 
prior  to  the  execution  of  the  application  task  and  determines  the  set  of 
application  tasks  which  may  have  been  effected  by  that  task.  Tasks  that  have 
not  operated  upon  data  altered  by  task  being  rolled  back  are  not  affected  by 
the  procedure.  The  rollback  procedure  attempts  to  minimize  the  time  and 
space  requirements  for  recovery. 


w* 


1,  Introduction 


Distributed  data  base  management  systems  (DDBMS)  have  the  potential  to 
make  a  significant  Impact  on  the  way  data  is  viewed  and  processed.  The  ability 
to  easily  and  safely  access  data  controlled  by  several  different  computers  has 
been  a  long  standing  goal  of  workers  in  the  data  base  area.  Progress  toward 
this  goal  has  accelerated  rapidly  in  both  academic  and  industrial  environments. 
However!  many  problems  still  require  efficient  solutions.  One  of  these  problem 
‘ areas  that  can  have  a  significant  performance  impact  is  rollback  and  recovery* 
which  is  the  topic  of  this  paper. 

1.1  Distributed  Data  Base  Management  Systems 

Many  forms  of  distributed  data  base  management  systems  have  been 
studied  [1-7].  All  distributed  data  base  configurations  can  be  described  as 
a  collection  of  host*  back-end,  or  bi-functional  machines.  A  host  machine  is 
a  processor  which  executes  data  base  application  tasks.  The  data  base  operations 
requested  by  a  host  machine  are  then  performed  by  a  back-end  machine.  A 
bi-functlonal  machine  contains  software  to  carry  out  both  the  host  and  back-end 
functions.  Figure  1  illustrates  a  DDBMS  with  host*  back-end*  and  bi-functional 
processors . 

1.2  Recovery  in  a  DBMS 

The  recovery  mechanism  is  essentially  the  same  in  all  single  machine 
data  base  management  systems.  During  the  execution  of  the  data  base  application 
tasks,  all  data  base  requests  are  logged  on  a  journal  file  (usually  a  tape). 
Whenever  a  data  base  request  results  in  a  modification  to  the  data  base,  the 
effected  pages  are  written  onto  the  journal  file  in  both  before  and/or  after 
Images.  If  a  point  of  inactivity  is  reached  in  the  processing  of  the  data  base, 
a  checkpoint  dump  of  DBMSjprlmary  memory  Is  taken.  All  journal  and  checkpoint 
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Information  oust  be  time  stamped  to  insure  proper  sequencing  of  the  recovery 
operation  *  which  Is  Implied  by  the  relative  position  of  data  In  the  single 
machine  case. 

If  an  application  task  should  terminate  abnormally.  Its  effect  on  the 
data  base  must  be  removed.  It  is  possible  in  an  interactive  environment  that 
data  written  by  the  terminating  application  task  may  have  been  used  by  other 
tasks  which  In  turn  performed  additional  modifications  to  the  data  base. 

This  phenomenon  of  an  application  task  using  incorrect  data  to  produce  additional 
incorrect  data  can  have  a  cascading  effect  throughout  the  data  base  with  a 
large  number  of  application  tasks  potentially  operating  with  invalid  information. 
Currently,  most  DBMS  users  avoid  this  problem  by  doing  updates  in  a  batch  mode 
at  a  specified  tine  and  allowing  only  interactive  query. 

In  order  to  undo  the  effect  of  an  abnormally  terminating  task  on  the 
d^ta  base,  a  rollback  procedure  is  necessary.  The  rollback  procedure  restores 
the  data  base  to  its  state  prior  to  the  initiation  of  the  erroneous  application 
task.  The  precise  form  of  a  rollback  procedure  varies  with  the  organization 
and  environment  of  the  DBMS. 

In  the  simplest  case  if  the  run  time  unit  of  the  DBMS  is  single  threaded 
and  operates  in  a  batch  environment,  then  the  data  base  can  be  restored  from 
*  checkpoint  taken  prior  to  the  initiation  of  the  task. 

In  the  more  complex  case  if  the  run  time  unit  of  the  DBMS  is  multi¬ 
threaded  and  operates  both  on-line  update  and  batch  tasks  simultaneously,  then 
one  of  two  basic  approaches  is  possible.  The  simpler  approach  is  to  roll  back 
fill  tasks  which  either  have  executed  or  are  executing  to  the  time  of  initiation 
o*  fht*  faulty  tns*.  If  this  procedure  is  followed,  the  integrity  of  all  portions 
of  £he  oata  base  will  be  preserved,  but  at  a  potentially  high  cost,  since  it  is 
possible  chat  tasks  which  have  no  interaction  with  the  terminating  task  may  be 
rolled  back  needlessly.  The  more  difficult  approach  suggests  that  only  processes 


which  themselves  have  used  contaminated  data  be  rolled  back.  In  »ost  cases 
this  would  involve  both  fewer  tasks  and  less  data.  In  either  ease,  the  roll¬ 
back  procedure  has  the  following  basic  steps: 

1.  The  data  base  is  restored  to  the  first  checkpoint  after  the  initiation 
of  the  faulty  task  (if  a  checkpoint  has  been  taken  in  that  time  frame). 

*  2.  The  page  images  prior  to  each  operation  from  the  checkpoint  to  task 

initiation  are  written  back  to  the  data  base.  It  should  be  noted  that 
the  page  images  are  applied  in  reverse  order  (hence,  the  term  rollback). 

Either  approach  to  the  rollback  of  an  Incorrect  application  program 

will  maintain  data  base  integrity  at  the  cost  of  halting  some  or  all  data  base 

activity.  While  the  integrity  of  the  data  base  is  preserved,  there  can  be  no 

guarantee  that  any  erroneous  information  obtained  by  a  user  from  an  application 

task  that  terminated  between  the  initiation  of  the  faulty  application  task  and 

the  beginning  of  the  rollback  procedure  can  be  corrected. 

2.  The  Problem  of  Recovery  and  the  DDBMS 

The  distribution  of  a  data  base  system  over  several  processors  Increases 
the  complexity  of  the  recovery  problem.  Just  the  interprocessor  communications 
overhead  can  result  in  more  time-consuming  rollback  operations  if  several 
processors  are  required  to  participate.  It  is  also  likely  to  be  the  case  that 
within  a  DDBMS  there  is  a  larger  number  of  programs  interacting  than  in  a  single 
u^ichine  system.  Hence,  the  complexity  and  effect  of  any  rollback  procedure  may 
r.e  compounded. 

7.1  Possible  DDBMS  Recovery  Alternatives 

There  are  three  basic  approaches  to  recovery  in  a  DDBMS. 

1.  Design  the  data  base  to  permit  only  controlled  or  restricted  interaction 
among  application  tasks. 

2.  Extend  the  single  machine  recovery  mechanism  to  the  distributed  system. 
This  approach  would  entail  rolling  back  all  data  bases  on  all  back-end 
processors  in  the  system  to  the  point  of  initiation  of  the  faulty  task. 
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3.  Use  a  selective  recovery  mechanism  to  roll  back  only  those  tasks 
which  have  used  data  provided  by  the  erroneous  or  terminated  task. 

2.2  Analysis  of  Alternatives 

The  three  approaches  to  r-.  covery  In  a  distributed  DBMS  that  are  listed 
abpve  represent  widely  differing  philosophies.  Each  approach  has  merit  for 
specific  types  of  organizations  and  data  processing  facilities.  The  criteria 
used  here  to  evaluate  these  alternatives  are  based  upon  the  recovery  procedure's 
‘  effects  upon  system  throughput,  as  well  as  data  availability  and  the  degree 
of  data  integrity  maintained  ^ithin  the  system. 

The  first  approach,  avoiding  integration  in  the  data  base,  has  little 
appeal  to  the  designer  of  a  DDBMS,  although  in  practice  this  might  be  the  most 
commonly  used  technique  since  many  users  of  data  base  systems  on  single  machines 
feel  that  avoiding  integration  is  the  only  reliable  means  of  insuring  data 
integrity.  If  this  user  philosophy  were  applied  to  a  DDBMS,  very  inefficient 
utilization  of  the  distributed  system  would  result.  In  order  to  avoid  the  need 
for  a  sophisticated  recovery  mechanism  in  a  DDBMS,  two  tasks  would  not  be  per¬ 
mitted  to  have  simultaneous  update  capabilities  to  the  same  data  base.  For  an 
application  system  under  this  requirement,  the  DDBMS  recovery  problem  can  be 
simplified.  An  on-line  inquiry  batch  update  system  would  fall  in  this  category. 

If  the  single  machine  approach  is  extended  to  a  DDBMS,  then  the  entire 
data  base  would  be  unavailable  during  recovery.  In  a  system  with  a  large 
number  of  back-end  or  bi-functional  processors,  this  approach  could  result  in 
the  recovery  of  a  small  portion  of  a  data  base  preventing  usage  of  a  large, 
correct  segment  of  the  data.  The  communication  process  involved  with  this 
technique  is  that  a  message  roust  be  transmitted  to  all  back-end  processors 
indicating  that  recovery  roust  begin  and  the  time  of  Initiation  of  the  faulty 
program.  This  system-wide  recovery  approach  insures  that  all  effects  of  the 
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erroneous  application  program  have  been  removed  from  the  data  base.  The 
main  drawbacks  to  this  method  are  that  access  to  uncffcctcd  portions  of  the 
data  base  is  prevented  and  that  unnecessary  rollbacks  may  occur. 

A  selective  recovery  mechanism  would  overcome  the  main  deficiency  of 
the  system-wide  recovery  strategy  by  rolling  back  only  those  application 
tasks  that  are  operating  with  tainted  data.  Overall  system  throughput  would 
increase  under  these  circumstances,  as  would  accessibility  to  the  data  base. 

In  order  for  a  selective  recovery  scheme  to  be  worthwhile,  data  base 
integrity  must  be  maintained.  Therefore,  the  scheme  must  be  drtaln  of 
including  all  tasks  that  have  used  incorrect  data  in  the  recovery  process. 

In  order  to  accomplish  selective  rollback,  information  on  the  interaction 
between  application  tasks  must  be  maintained.  This  Interaction  information 
would  take  the  fora  of  a  potential  shared  data  list  which  can  be  computed 
from  the  sub-schemas  of  the  application  tasks  prior  to  execution. 

The  communication  overhead  which  potentially  has  the  most  significant 
performance  effect  in  a  DDBMS  must  not  exceed  one  transmission  to  each  back¬ 
end  processor  if  the  method  is  to  be  effective.  The  computational  overhead 
involved  in  a  selective  recovery  strategy  must  be  maintained  at  a  level 
where  it  is  not  significant  in  terms  of  system  performance.  A  selective 
recovery  mechanism  which  satisfies  the  performance  requirements  listed  above 
has  the  potential  for  better  performance  in  a  DDBMS  than  the  recovery  schemes 
discussed  previously. 

In  distributed  data  base  systems  which  are  highly  Integrated  and  support 
au It  1- threaded  updating,  a  selective  recovery  technique  is  required  if  both 
performance  and  integrity  are  to  be  preserved. 

J*.  A  Selective  Recovery  Methodology 


The  following  sections  explain  a  procedure  which  meets  the  necessary 
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criteria  for  selective  rollback  as  described  above.  In  addition,  some 
comments  are  made  concerning  the  role  of  the  DBA  with  respect  to  4  DDBMS 
system.  The  procedure  is  oriented  toward  a  CODASYL-typc  DBMS,  although 
the  same  general  techniques  are  applicable  to  any  type  of  data  base  system. 

3.1  Definition-Time  Recovery  Processing 

As  previously  mentioned,  the  proposed  selective  recovery  methodology 
for  distributed  data  base  systems  requires  processing  at  data  definition 
time,  as  well  as  run  time.  When  a  new  sub-schema  Is  created,  a  potential 
shared  data  list  is  computed  intersecting  all  sub-schemas  of  that  schema. 

The  potential  shared  data  list  Indicates  record  and  set  types  that  are  in 
conraon  with  other  sub-schemas. 

Since  each  application  task  Invokes  exactly  one  'sub-schema  during  Its 
execution,  the  potential  data  overlap  of  any  two  application  tasks  can  be 
determined  from  their  potential  shared  data  lists.  In  order  to  maintain 
the  data  overlap  information  at  execution  time,  the  activation  of  a  data 
base  application  task  must  result  in  a  message  being  transmitted  to  all 
applications  that  have  the  potential  to  share  data  with  that  task.  The 
message  indicates  the  application  task  and  sub-schema  names.  The  information 
relating  active  application  tasks  and  sub-schemas  Is  maintained  in  the  data 
dictionary.  When  an  application  task  terminates,  a  similar  message  is  sent 
to  all  tasks  with  intersecting  potential  shared  data  llata. 

Situations  may  arise  in  Integrated  data  bases  i  which  application 
tasks  share  record  types,  but  do  not  operate  upon  the  csw tests  of  all  data 
items  In  the  record.  A  similar  possibility  is  that  the  application  task  may 
access  some  data  items  in  a  read-and-print  mode.  In  eitheT  af  these  situations, 
an  incorrect  value  in  a  data  item  may  not  be  critical  to  the  function  of  the 


8 


program.  Rolling  back  a  Cask  due  Co  an  incorrect  value  in  a  non-crltlcal 
data  item  would  have  an  adverse  effect  on  ays ten  performance. 

The  Identity  of  non-crltlcal  data  items  is  heavily  application  task 
dependent  and  can  in  no  way  be  Inferred  from  a  sub-schema  description.  Since 
the  CODASYL  specifications  [8J  do  not  provide  for  the  identif lea Cions  of  non- 
critical  data  items  for  recovery  purposes,  some  additional  mechanism  for  their 
identifications  must  be  provided  to  the  data  base  administrator.  The  simplest 
approach  would  be  to  maintain  in  the  data  dictionary  a  list  of  non-crltlcal 
data  Items  for  each  application  task. 

When  sub-schemas  are  Intersected  to  form  the  potential  shared  record 
l isc,  non-critical  data  items  should  be  removed  from  the  intersection  of  the 
records.  Only  those  records  which  intersect  on  critical  data  Items  should  be 
Included  in  the  potential  shared  data  list.  Figure  2  Illustrates  the  potential 
^nared  data  list  for  a  sample  application  task,  A. 

*•2  Logging 

The  functional  back-end  processor  controls  data  base  access  and,  therefore, 
is  the  appropriate  location  to  maintain  the  logs  of  data  base  activity.  Since 
♦  back-end  processor  (or  a  bi-functional  machine  serving  as  a  back-end)  may 
«erve  a  large  number  of  application  tasks,  the  amount  of  recovery  information 
..  it. c  be  minimized.  Many  existing  single  machine  data  base  systems  save  the 
>2fore  and  after  images  of  each  page  that  Is  altered  as  a  result  of  a  DML 
tacement.  For  example,  in  a  CODASYL  DBMS,  changes  to  s«t  structure  can  affect 
man y  pages  and  consequently  consume  a  large  amount  of  file  space.  In  order  to 
a jcc  the  amount  of  log  file  space  required,  an  inverse  DML  rollback  technique 
■»'.  Lc  used.  The  inverse  technique  requires  little  primary  memory,  since  for 
-lie  most  part  existing  DML  functions  can  be  used  to  perform  the  rollback 


Potential  Shared  Data  List  (for  Task  A) 


Task 

Record 

B 

ri 

B 

*2 

C 

r2 

D 

r2 

Figure  2 

Sample  Potential  Shared  Data  List 
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operations.  Table  1  lists  the  CODASYL  DML  verbs,  the  information  that  a 
back-end  processor  must  save  to  roll  back  that  verb,  and  the  inverse  actions. 

Whenever  a  DML  verb  is  executed  by  a  back-end  processor,  a  log  file 
entry  is  written.  Figure  3a  depicts  the  format  of  a  log  file  entry  for  a 
DML  verb.  Note  that  the  entries  hrve  variable  lengths.  In  addition^to 
recording  the  DML  verbs  that  have  been  executed,  the  log  file  must  also 
contain  restart  information  on  all  application  tasks.  Restart  information 
identifies  a  stable  point  at  which  an  application  program  can  be  restarted. 

By  default,  the  system  will  write  a  restart  entry  whenever  an  application  task 
is  initiated.  It  is  also  desirable  to  permit  the  programmer  the  ability  to 
Indicate  a  restart  point  in  a  task.  The  CODASYL  specifications  do  not  provide 
a  facility  for  this  operation.  However,  UNTVAC’s  DMS-1100  has  a  similar  feature 
in  the  LOG  verb  [9].  The  format  of  a  restart  entry  for  the  log  file  is  shown 
in  Figure  3b. 

Figure  4  gives  some  sample  DML  commands  and  their  resultant  log  file 
entries. 

In  certain  cases,  particularly  a  strict  retrieval  environment,  the 
logging  of  read  operations  may  produce  a  large  number  of  entries  on  the  log 
file  that  will  never  be  applied  in  any  rollback  situation.  Considerable  roll¬ 
back  overhead  could  be  saved  if  the  data  base  administrator  were  provided  the 
option  of  shutting  off  the  logging  facility  for  retrieval  operations  on  selec¬ 
tive  tasks.  This  could  be  accomplished  at  task  initiation  time. 

3.3  Rollback 

When  the  DBMS  software  on  a  host  processor  determines  ^that  an  application 
cask  has  terminated  abnormally,  rollback  procedures  are  initiated.  The  host 
processor  notifies  all  back-end  processors  for  this  task  that  rollback  must 
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DHL 

Verb 

Effect  on 

Data  Base 

Recovery 

Information 

Recovery 

Action 

ACCEPT 

None 

M/A 

N/A 

CONNECT 

Changes  Pointers 

Record  A  Sec  Name* 

DISCONNECT 

'  DISCONNECT 

Changes  Pointers 

Record  A  Sec  Names 

CONNECT 

ERASE 

Removes  Record 
and  Members 

Images  of  All  Erased 
Records ,  Set  Memberships 

All  Records 

FIND 

None 

M/A 

M/A 

FINISH 

None 

• 

M/A 

N/A 

FREE 

None 

M  /A 

N/A 

GET 

None 

N/A 

N/A 

KEEP 

None 

M/A 

N/A 

MODIFY 

Changes  Record 

Contents 

Old  Record  Image 

MODIFY 

ORDER 

Changes  Pointers 

Set  Pointers  la  Old 

Order 

Reorder  Using 
Old  Pointers 

READY 

None 

N/A 

N/A 

STORE 

Changes  Record 

Contents  and  Pointers 

Record  Name 

ERASE 

REMONITOR 

None 

N/A 

N/A 

USE 

None 

N/A 

% 

N/A 

Table  1 

Recovery  Information  and  Action  for  ML  Verbs 


RECORD  OCCURRENCE  DHL  ROLLBACK 

OR  ’  OPERATION  INFORMATIOI 

SET  ID 

TYPE 


b.  Restart  Entry 
Plgure  3 

Log  File  Entries 
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Commands  Received  By 

Back-End  Processors  Log  File 


TJae 

Command 

Task 

Time 

Occurrence 

Operation 

C0 

Initiate  A 

A 

'o 

— 

RESTART 

*1 

Restart  Point-C 

C 

'l 

— 

RESTART 

*2 

A:  STORE  ^ 

A 

*2 

ri 

STORE 

*3 

C:  GET  r2 

C 

*3 

r2 

GET 

*4 

Initiate  B 

B 

— 

RESTART 

*5 

A:  MODIFY  r2 

A 

C5 

r2 

MODIFY 

*6 

A:  MODIFY  t± 

A 

<6 

rl 

MODIFY 

C7 

Initiate  D 

D 

C7 

— 

RESTART 

*8 

D:  GET  tx 

D 

e8 

rl 

GET 

*9 

B:  GET  r2 

B 

‘9 

r2 

GET 

eio 

B:  GET  r2 

B 

rt 

M 

O 

GET 

Figure  4 


Sample  tog  File 
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occur  and  provides  the  task  name,  Its  initiation  time,  its  potential  shared 
data  list,  and  a  list  of  its  areas  which  are  open  for  update  as  parameters. 

The  method  for  identifying  the  back-end  processors  for  a  given  task  is  explained 
in  Reference  [10].  In  the  ensuing  presentation,  this  task  shall  be  known  as 
the  primary  rollback  task. 

Each  back-end  processor  that  receives  the  rollback  message  must  refuse  to 
accept  any  DHL  operations  accessing  the  areas  updated  by  the  terminating  task. 
T«ie  following  rollback  procedure  is  then  carried  out. 

1.  Read  the  log  file  backwards  to  locate  the  Initiation  point  of  the  task. 

2.  Read  the  log  file  forward  from  that  point  and  perform  the  following 
operations,  depending  upon  the  entry  on  the  log  file: 

a.  If  the  entry  is  an  update  entry  for  the  task  that  is  being  rolled 
back*  make  an  entry  in  the  update  list  which  indicates  the  record  or  set 
occurrence  whose  contents  have  been  modified.  An  entry  in  the  update  list 
consists  of  an  ordered  pair  of  record  or  set  type  and  occurrence  identifiers. 
Copy  this  log  file  entry  onto  the  rollback  file. 

b.  If  a  MODIFY  entry  for  the  task  being  rolled  back  alters  the  contents 
ot  a  record  occurrence  that  was  previously  MODIFIED  (this  is  indicated  by  the 
presence  of  the  record  occurrence  on  the  update  list),  no  action  is  taken  with 
aspect  to  either  the^update  list  or  rollback  file.  This  will  insure  that  an 

dated  record  is  restored  only  once  to  its  earliest  value  in  the  rollback 
procedure. 


c.  If  an  entry  for  an  application  task  other  than  the  primary  roll- 
Oi/ck  cask  references  a  record  or  set  occurrence  for  which  an  update  list  entry 
r’ust:-,  and  an  entry  for  that  task  and  record  or  set  type  exists  in  the  potential 
shared  data  list,  that  task  must  also  be  rolled  back.  Rollback  of  this  task 
just  occur  since  the  task  may  be  operating  with  incorrect  data.  The  task  name 
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and  time  of  this  entry  arc  saved  in  a  secondary  rollback  list. 

d.  All  entries  on  the  log  file  for  tasks  In  the  secondary  rollback 
list  are  ignored. 

a.  All  entries  on  the  rollback  file  for  tasks  that  do  not  have  entries 

in  the  potential ^shared  data  list  of  the  primary  rollback  task  are  Ignored. 

% 

f.  All  entries  for  non-update  DHL  commands  that  operate  on  record  or 
or  set  occurrences  not  In  the  update  list  are  Ignored. 

g.  Any  primary  rollback  task  retrieval  entries  oo  the  log  file  are 

Ignored. 

e 

3.  When  the  log  file  has  been  processed  up  to  the  time  of  termination, 
the  restoration  of  the  portions  of  the  data  base  effected  by  the  primary 
rollback  task  is  performed  by  processing  the  rollback  file  la  reverse  and 
executing  the  rollback  actions  indicated  in  Table  1. 

4.  The  log  file  is  read  backwards  in  order  to  locate,  for  each  task  in 
the  secondary  rollback  list,  the  restart  point  immediately  preceding  the  time 
at  which  the  incorrect  operation  was  detected. 

5.  Messages  are  transmitted  to  the  host  processors  for  the  tasks  in  the 
secondary  rollback  list,  indicating  that  the  tasks  should  be  rolled  back  to 
the  specified  restart  point.  The  host  processors  will  then  suspend  those 
application  tasks  and  send  the  appropriate  rollback  Information  to  the  back¬ 
end  processors  for  those  tasks. 

Figure  5  Illustrates  the  resulting  rollback  file,  update  list,  and  secondary 
rollback  list  if  the  sample  application  task  A  of  Figure  4  were  to  be  rolled 
back.  The  potential  shared  data  list  of  Figure  2  Is  assumed  in  this  example. 
Careful  observation  of  Figures  2,  4,  and  5  will  lead  to  the  following 

conclusions : 

1.  C  is  not  rolled  back  since  It  accesses  r^  before  A  updates  r^. 
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»nn back  File  (Operations) 


STORE  r. 


MODIFY  r- 


odate  List 


Actions 

Jf  Task  A  will  be  rolled 
back  to  time  tQ. 

2*  will  be  removed  from 

the  data  base. 

3#  r2  will  be  restored  to 

its  status  before  time  t^. 


Sec  on  d  ary  Rollback  List 


Figure  5 


Results  of  Rolling  Back  Task  A 


i 
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2.  D  Is  not  rolled  back  since  Is  not  in  the  potential  shared  data 

list  (i.e.  it  is  not  a  critical  record  for  D). 

3.  The  MODIFY  command  is  not  rolled  back  since  it  is  preceded  by  a 
STORE  command. 

4.  Although  it  is  not  explicitly  shown  in  the  figures t  the  GET  r^ 

* 

conmand  at  time  t^  will  be  Ignored  during  rollback  processing,  since  B  will 
have  been  added  to  the  secondary  rollback  list  after  processing  the  log  file 
entry  for  time  t^. 

3.4  Responsibilities  of  Data  Base  Administrator 

The  distribution  of  a  DBMS  over  a  computer  network  enormously  complicates 
the  data  base  administration  function.  If  a  recovery  scheme  similar  to  that 
proposed  in  this  paper  is  Implemented,  the  DBA  must  make  decisions  that  will 
have  substantial  impact  on  the  time  required  for  recovery.  Perhaps  the  most 
important  factors  are  the  distribution  of  the  data  across  machines  and  the 
amount  of  data  integration.  As  distribution  and  integration  of  data  increase, 
the  data  base  becomes  more  accessible  to  a  larger  number  of  users.  At  the 
same  time,  recovery  operations  become  Increasingly  complex.  This  quandry 
reduces  to  the  classical  data  processing  tradeoff  between  flexibility  and 
efficiency.  It  is  the  role  of  the  data  base  administrator  to  balance  these 
two  seemingly  conflicting  factors. 

4.  Conclusion 

The  rollback  of  an  application  task  by  a  back-end  processor  is  the  central 
element  in  any  recovery  scheme  for  a  distributed  data  base  management  system. 

In  a  highly  integrated  data  base,  the  procedure  may  have  to  be  repeated  several 
times  until  no  new  secondary  rollback  lists  are  generated.  Rollback  can  be 
executed  concurrently  on  distinct  back-end  processors.  However,  a  back-end 
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processor  can  rollback  only  one  application  task  at  a  time*  It  is  important 
to  note  that  the  recovery  procedure  docs  not  allow  (or  redundant  copies  of  data 
at  different  back-end  processors.  Although  redundancy  is  unnecessary  in  a 
truly  distributed  DBMS,  there  are  certain  circumstances  in  which  practical 

considerations  may  justify  redundancy  [1,3).  As  in  all  other  situations  of 

<• 

this  nature,  the  DBA  must  decide  on  redundancy. 

The  rollback  procedure  presented. in  this  paper  provides  a  mechanism 
lor  efficient  and  complete  recovery  in  a  distributed  data  base  management 
system.  The  development  of  an  efficient  recovery  mechanism  can  have  a  signi- 
i leant  impact  on  the  design  and  usage  of  distributed  data  base  systems.  One 
Important  design  aspect  that  recovery  can  impact  is  deadlock  handling.  Due 
to  potential  inefficiencies  in  recovery  of  distributed  data  bases,  it  has 
been  argued  that  deadlock  prevention  is  more  efficient  than  deadlock  detection 
tor  a  distributed  DBMS  [11].  However,  an  efficient  recovery  mechanism  can 
make  deadlock  detection  more  attractive. 

An  efficient  and  complete  recovery  technique  could  provide  data  base  users 
with  sufficient  confidence  in  a  DBMS  to  allow  the  formulation  of  integrated, 
distributed  data  bases.  Without  that  confidence,  the  progress  in  distributed 
data  base  systems  will  be  severely  impeded  by  lack  of  acceptance  in  the  data 
processing  environment.  The  recovery  procedure  presented  in  this  report  is  a 
ritep  coward  developing  that  user  confidence  in  data  base  systems. 
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